细品中台

两年前正当中台概念爆发的时候，我曾经写了三篇文章（什么是中台、怎么建中台、网易杭研的中台往事）对中台做了一次梳理，这两年，中台仍然持续是热门话题（虽然没有更热），我们及行业对中台的理解和实践也有了长足的进步。

从我们而言，两年前我们的中台和支撑技术（如网易轻舟和有数）只能说有了基础，这两年都成熟很多。我们也服务了一些外部客户，获得了一些非互联网行业中台经验。这些内外部经验我们进行了总结，出品了极客时间《数据中台》专栏。

从行业而言，有了滴滴、头条、美的等更多的行业案例，也有更多的行业专家针对中台话题发表了更多思考。如王健老师出品了极客时间专栏《讲透中台》，在我看来应该是在业界第一次完整的提出中台的建设方法论；钟华老师新写了《数字化转型的道与术》，把中台融入到企业数字化转型的大框架内；企业服务领域的老江湖用友也出了《数字化中台》，全面阐释业务、数据、智能、技术等中台体系；刘天（三爷）老师写了《中台产品经理宝典》；付晓岩老师、老K等也都发表了相关思考，就连刘润老师也止不住的把《尴尬的中台》每年旧文重发一次（似乎只字未改）。至于业界实践最多的数据中台，厂商出书已经形成一种风气，似乎不出书就显得不够格（我们没出书但也出了极客时间专栏）。

这段时间，我一直在梳理两年来我们和业界的相关进展，思考，总结，以下就是工作成果。全文约两万字，分上下两篇，上篇是中台篇，介绍中台相关的通用话题和业务中台，下篇是数据中台篇，专门介绍数据中台。只对数据中台感兴趣的朋友可以跳到下篇。

两年前读过的老朋友完全不用担心内容重复，和刘润老师不同，虽然我的核心思想是一脉相承的，但内容囊括了这两年的很多进展，总体丰富很多。王健老师也是这样，虽然两年前写了系列文章，但专栏进一步提出了方法论。钟华老师的思考则是突破了中台上升到企业数字化转型的大局观。

我们都在要求自己进步。

「中台篇」

01

中台是怎么来的

大家都知道中台是阿里提出的，问题是阿里为什么会想到中台这一招。关于这个缘由，有正史和野史两个版本。

1. 正史版

正史来自于钟华老师的《企业IT架构转型之道—阿里巴巴中台战略思想与架构实践》。说是2015年中的时候，马老师带领一众高管芬兰游戏公司Supercell，惊呼原来世界上还有这么高效的公司，回来后学习Supercell就提出中台战略。

Supercell是一家游戏公司，2010年中成立，马老师去看的时候才五年，但营收已经超过200亿美金，更神奇的是只有不到200人。2015年的阿里则是成立已经17年，马老师都熬不牢半退休了，营收才943亿人民币，员工数却高达34985，还正值马老师交棒给老陆后狂推来往而失败，正处于战略上的焦虑期。两厢对照，肯定会觉得Supercell真的是神，不服不行。

马老师应该特别喜欢琢磨公司的组织模式（你看阿里经常调组织架构），所以自然就发现Supercell这家公司很特别。Supercell的搞法是所谓的“细胞-部落”式，细胞是工作室，每个工作室就几个人，负责一个游戏，部落是共享的职能，负责公共、通用的游戏素材、算法等，为各工作室提供高效的支撑。这样的模式让Supercell特别善于创新试错，据说一个小团队几周时间就可以研发出一款新游戏推向市场，如果这个游戏失败了，公司甚至会举办仪式来庆祝从失败中学到了东西。

回来后，年底阿里就宣布全面启动中台战略。

当然，阿里能全面搞中台战略，除了Supercell的神启，也是要有事实基础的。这个基础就是2009年成立的共享业务事业部，这个事业部在2015年的时候，已经搞了用户中心、商品中心、交易中心等十几个中心。也就是说当时阿里最具特征的业务中台已经相当有雏形了。

2. 野史版

野史版的故事来自于阿朱。话说2013年5月10日晚，数万阿里人相聚黄龙体育中心，参加淘宝十周年的纪念晚会。但大家知道这个晚会不仅是纪念淘宝十周年的，更重要的是马老师要在会上宣布退休，交棒给老陆。我虽然不是阿里人，但也受邀在现场亲眼见证了交接过程。马老师一如既往的慷慨激昂，高呼“要相信年轻人”、“从明天起，生活就是我的工作”，然后老陆上台，马老师退场。

但马老师当然是退而不休。为了安全退休，阿里被拆分为25个事业部，并且实行了合伙人制。25个事业部各自为政，老陆上台后，根本搞不定这25路诸侯，无奈之下只能剑走偏锋，拼命做来往。老陆的算盘是要是来往做大，每个事业部都得求着来往要流量，那时我还不是让谁干嘛就干嘛？可惜来往没成，25个诸侯群起而轰之（老陆命令所有员工至少拉100个来往好友否则不发年终奖，把各路诸侯都得罪了），马老师把老陆废了，悄咪咪换上老逍。

老逍上台，也得想办法解决这个诸侯的问题啊，不然干不了两年也得下台（甚至更严重，老陆后来不久连合伙人的资格都被废了）。2015年5月老逍上任，年中马老师带高管拜访Supercell，大概率老逍是一起去了的。我觉得说是马老师受到了Supercell的神启，不如说是老逍受到神启。我想老逍一看Supercell的搞法，肯定会觉得太对胃口。只要搞“大中台”，美其名曰大家不要重复造轮子，25个事业部就变成了“小前台”，这不就把诸侯的问题解决了吗。中台的负责人，正是老逍多年的好战友行颠。

我想阿朱讲这个故事的用意可能不是说中台不行，反而是给各位老大提个醒，如果你想削各路诸侯的权的话，可以搞中台啊。

有句著名的伪名言叫“历史是个任人打扮的小姑娘”，阿里中台的正史和野史，都有真实的故事，但对背后动机的解读就完全不同了。我个人觉得，抱着兼听则明的原则，姑且两边都信一点为好。

02

阿里的花式中台打法

虽然钟华老师在书里很低调的说中台并不是阿里首先提出的词语，但一般都认可是阿里首先把中台概念发扬光大的，我们先来看阿里的中台都是哪些。

我们先看阿里刚提出中台时的样子，往往这个时候的中台最能反映初心和精髓。阿里最初提出的中台架构是双中台：业务中台+数据中台，分别对应两本书，都在2017年出版。

第一本是《企业IT架构转型之道：阿里巴巴中台战略思想与架构实践》，这本书应该算是阿里第一次正式提出中台的概念，不过只介绍了业务中台，没有任何一个地方提及数据中台。这本书并没有给中台下过一个明确定义，但通观全书基本可以理解阿里的业务中台就是共享业务事业部及其所构建的如下图所示的共享服务体系，包括会员、商品、交易等20多个公共的、通用的业务服务，前者是中台的组织层面，后者是中台的系统层面。

第二本是《大数据之路：阿里巴巴大数据实践》。这本书明确给出了阿里集团数据中台的概念，即“阿里巴巴数据技术及产品部定位于阿里集团数据中台”，书中主要介绍了阿里集团内部进行数据整合及管理的方法论，也就是OneData、OneID、OneService，这套体系的主要应用是构建了阿里集团的数据公共层。

由此可见，阿里一开始提出的“双中台”的概念是很清楚、很好理解的。双中台都涉及组织和系统两个维度，组织维度都有负责的部门，系统维度业务中台就是共享的业务中心，数据中台的就是数据公共层。

但是后来阿里好像就有点放飞自我了，各种花式运用层出不穷，对中台的运用达到了出神入化的状态。

比如去年说上了用户行为分析、CDP就叫中台，3年要帮客户建100万中台。当时我写过一篇我已经不能理解阿里说的中台是啥了，表示不解。今年又说要云钉一体，做厚中台，又说这个中台是个操作系统，钉钉是操作系统的核心。一般理解操作系统是个软件概念，阿里号称自己是商业操作系统，把操作系统的概念泛化了，这也好理解，但说中台也是个操作系统，就不太好理解了。这个操作系统是阿里商业操作系统里面的一个子操作系统？

另一方面，据说阿里已经在拆中台，要把中台做薄。一边做厚，一边做薄？自己拆中台了却要帮客户建100万个中台？不是我不明白，这世界变化快！我相信很多人都是这样的感觉吧。实事求是的说这些说法也不一定冲突，比如做厚中台指的是做厚阿里云的中台，做薄中台指的是做薄阿里集团的中台。但说法多了，确实容易把大家搞晕。

我觉得对咱们普罗大众来说，要学习阿里的中台还是看最初的双中台比较好。

03

网易杭研的中台实践

网易有两套比较成熟的中台体系，一是游戏中台，二是杭州研究院所构建或参与的系列中台。游戏中台我没参与不熟悉，大家大致可以理解为类似Supercell的做法，杭研相关的系列中台则是我的主要工作。

1. 创新中台

网易杭研成立于2006年，核心职责是为集团孵化创新业务，今天很多人知道的云音乐、严选、云课堂、Lofter、考拉海购，早一些的网易相册、网易博客，To B的智慧企业、网易数帆等都来自杭研的孵化。为了更好的支撑创新业务发展，杭研从一开始就逐步构建各类专业能力部门（内部称为公技部门）提供大量公共的技术平台或专业服务。

整个杭研构建的这些专业能力部门，可以认为共同形成了一个创新中台。两年前我曾写过一篇文章介绍杭研的这段往事，有兴趣深入了解的可以看看。大致而言，我们围绕互联网类创新业务发展所需的市场研究、用户研究、用户体验、敏捷项目管理、移动开发、个性化推荐、商业智能、内容安全等都设置了专项的部门。这些部门一方面提供专业的人力服务，另一方面也积极研发相应领域的系统和方法论。

大家可能认为这些部门和阿里的双中台大相径庭，不能算做中台，但整体来看，它们共同构成了一个强大的支撑互联网业务创新发展的公共能力，这些能力很大程度上以软件的方式提供，而这些部门又和业务贴的很紧，具备互联网行业特征，因此称为面向互联网业务的创新中台是很恰当的。王健老师在《白话中台战略2：中台到底长啥样？》一文中提到“组织中台很像企业中的内部风投和创新孵化机构”，杭研创新中台可以说是组织中台。

当然，我也认为杭研的创新中台确实不算最典型的中台，这些专项部门往往都只在一个阶段存在，一般几年之后在一个专项上的能力建设达到比较高的水平后，我们往往选择将这些部门的专业服务人员分拆到各对口业务，而只留下产品化的成果。这样一个中台部门就“转化”成为一个技术平台，这样的转化在我们看来实属平常。

最近两三年，我给多家企业做过创新中台的分享，很多企业都表示我们的机制挺不错，很值得研究和学习。可能因为毕竟如我们这样十多年通过研究院在创新中台的支撑下不断的探索创新业务（还挺跨界）也还算有些成绩的公司极少，大量的是创新乏力的企业，和我们类似搞过面向创新的研究院或创新院的要么没搞成（如曾经轰轰烈烈的盛大创新院）或因为太成功但把研究院搞没了（如做出微信的腾讯广州研究院）。但我知道绝大多数企业也只能说说而已，真的要搞好一个面向创新的研究院和创新中台谈和容易。

2. 数据中台

我们构建的最多的是数据中台，包括集团级的数据中台，也包括严选和云音乐等事业部级的数据中台。

我们从2015年开始构建集团的数据中台。我们的做法和阿里是类似的，也是定位于建设集团的数据公共层。但因为我们的业务形态五花八门，不像阿里很多事业部都聚集电商领域，所以我们的数据公共层就比较薄，主要就聚焦在用户标识、用户画像和用户关系层面。经过6年的建设，当前非游戏业务已经完全依赖于我们建设的数据公共层，大量的广告投放和推广都依赖我们提供的更为全面的精准的用户标签。

严选和云音乐也构建了数据中台，这些数据中台比集团的做的更厚，不但包含事业部级别的数据公共层，还包含了很多子业务的数据集市，数据中台团队也比集团数据中台团队规模更大。指标、模型、治理等数据中台的典型实践在这些事业部级的数据中台中体现的更为充分，这些中台对数据的获取效率、使用成本、质量和安全性起到的价值更为显著。严选的数据中台建设开始于2017年，是事业部里启动最早的，也最成熟，整体架构见下图，细节可关注严选技术团队2019年底的介绍（数据中台-企业的数据化引擎）。

3. 业务中台

我们从去年开始着力构建视频中台，因为集团有很多视频内容业务，如音乐、新闻、有道、Lofter等，还包括可通过内容带货的电商业务严选。视频中台的主要职责是视频的统一采买、统一加工处理和多渠道分发。

事业部里面，严选和音乐在业务中台上投入比较多。严选虽然体量不大，但链路上从研发生产直到销售配送，营销体系上除了主站还有淘系、京东等分销和企业内购等不同形态，业务复杂性其实非常高。为了提供可复用的业务场景解决方案，以较低的成本快速满足多个前台业务需求，严选自从2018年开始探索和构建中台能力，当前在库存、采购、品控、仓配、供应商等板块都实现了比较好的中台化。严选的中台建设有一个特点是并非整体成立了一个中台部门，而是在库存、采购等各个业务板块内部建设多个“小中台”。

音乐比较有意思的是App中台和曲库中台。音乐的App中台沉淀了大量音乐社区和社交类App的共性能力，使得我们在孵化和云音乐同类的声波、心遇等App时快了很多，有个突出例子是Clubhouse火了后两天就做出了类似功能。曲库中台负责源源不断的新歌入库，并针对歌曲内容进行深入的分析和挖掘，为各业务提供完整、准确的曲库信息，包括歌词、翻唱跟关联关系等，还提供听歌识曲等专业能力。

总的来说，我们的中台有几个特色。一是都是因地制宜逐步建设，投入较少，但效益比较扎实；二是创新中台；三是大部分中台不是集团级，而是事业部甚至是子业务内部的。其中后面两个特色比较适合我们横跨社交娱乐、电商、教育的多元化业务特征。

04

业界中台盘点

在阿里之外业务最常提到的中台可能是字节。字节在业界被称为App工厂，旗下头条、抖音、西瓜、懂车帝等多个内容型App都很牛，所以业界早就盛传字节有一套面向内容产品研发和运营的中台能力。关于字节中台的分享都不怎么深入，不过今天我们可以从字节开放的火山引擎一窥究竟。如下图所示，火山引擎开放的技术中台包括AI中台、多媒体中台、数据中台、研发中台和移动中台五大模块，其中能力最丰富的是AI中台和多媒体中台。这些能力大概率尚且只是字节中台能力的一部分而非全部。

一般情况下我都不认为一大堆技术组件的汇集能称为中台，因为在这些技术里面往往找不到和业务相关的字眼，字节的中台是我觉得极少的可称为技术中台的，因为字节的核心业务就是内容型业务，所以这些能力很多和业务就比较相关。但我觉得仍可以说字节的“中台味”不太纯，因为其中大多数都是业界比较通用的技术组件。

滴滴从2015年开始做中台，到2016年做了出行中台，很多出行业务都基于这个中台。基于出行中台孵化出了订单、计价、支付、passport、用户、触达等六大中台能力，这些能力2019年也开始支持非出行业务，演进为公司级的业务中台。除业务中台，滴滴还有比较庞大的团队做了数据中台。

京东2018年开启中台战略，主要通过组件化和平台化，面向“黄金交易流程”，涉及购物车、结算页、收银台、订单等核心交易模块。除了这一高层面的中台，一些子业务内部也有中台，购物车中台、结算页中台、订单中台等。以购物车为例，中台和前台是独立的两个部门，中台除了支持主站购物车外，还支持医药等垂直业务的中台。

以上都是互联网领域的案例，因为中台几年热度很高，一些非互联网行业也进行了中台建设，如美的和农业银行。

美的董事长方洪波在一次采访中介绍了美的的中台。以前美的是事业部制，高度分权，效率非常好。但随着数据时代的变化，变化越来越快，美的需要高度快速反应、敏捷性、韧性、灵活性，为此美的向互联网企业学习，开始转型，思路就是大平台、小组织、小团体、小单元、小业务、小分队。在后台之上建了两个核心，一个业务中台、一个技术部门，前方全是小的团队，区域的、产品的或以某一个业务板块划分。

农业银行提出了“薄前台、厚中台、强后台”的 IT 架构体系，其业务中台包括流程、服务和产品三个维度，流程维度包括风控、信用评价、反洗钱等4个模块，服务维度包括客户、员工、运营、渠道等8个模块，产品维度包括存款、信贷、支付结算等8个模块。看起来农行的中台建设已经蔚为大观。但从资料和对银行业的了解看，农行的以上中台大可能还是一种设想而非实际。不过农行的信贷中台看起来是实际落地了的，由于行业场景贷款和全局授信等需求，农行构建了如下图所示的信贷中台，支撑供应链金融、个人、对公等多个业务。

05

中台是什么

在看了阿里、我们及业界很多公司的中台实践案例后，为中台给出一个正式定义就比较容易了。

我两年前给中台下过一个定义（见[[什么是中台，什么不是中台]]）：中台是支持多个前台业务且具备业务属性的共性能力组织。参考这两年的实践经验和专家观点，我想对这个定义进行小幅修正，新的定义是：中台是以软件服务的形式提供共性业务能力的组织。

新的定义删除了“支持多个前台业务”不是因为这一点不重要，而是因为“共性”一词已经表达了这层含义。

这个定义有三个关键词：

• 中台必须是个组织：这一点是中台区别于其他能力复用形式的首要特点。阿里的双中台都有强大的组织（共享业务事业部和数据技术及产品部）来建设和运营；我们的中台也都有对应的组织建设，集团级的中台由杭研承担，部门级的中台也都有相应的组织负责建设；钟华老师认为“中台必须是值得企业投入独立团队进行运营的单元”；王健老师认为“组织可能不是中台建设的阻碍，而恰恰是中台建设的本质”。这都说明中台必须和组织相配套已经是行业共识。另一方面，中台是组织这点和和也提供共性能力的软件平台和技术平台（特别是和中台听起来有点像的中间件）好区分。业界有不少专家认为中台和中间件没什么两样（刘润老师似乎就是这么认为的），这是不对的。这并非我一个人的观点，王健老师在专栏中就指出技术中台和中间件是两回事，何况业务中台和数据中台；钟华老师明确的把中间件归属于后台。
  
  

• 中台提供的能力必须有业务属性：这是中台区别于其他能力复用形式的另一显著特点。从业界的典型实践看，业务中台提供的能力都是和业务领域相关的，数据中台提供的服务和指标也都是和业务特征相关的，中台的业务属性很浓。钟华老师认为“仅在纯技术层面进行沉淀和改进，其工作效率的提升还是有限的”，只有在业务层面做了沉淀，才可能为新建系统提供帮助，“采用这种方式的效率一定远超前一种”。虽然这一点并未形成高度共识（有些专家的定义比较泛），但我认为有没有业务属性会导致建设和运营方式显著不同（比方说有业务属性的你就买不到，否则你很可能可以买到现成的；有业务属性必须运营，没有业务属性可以只是运维），所以我还是坚持中台必须要有业务属性。另一方面，坚持这一标准有助于将中台和很多没有业务属性的技术平台（再次点名中间件）和典型的财法税等没有业务属性的后台部门区分开。
  
  

• 中台的能力必须要以软件服务的形式提供：这一点比较微妙，也可能挺有争议，但我认为是值得强调的。这涉及几个方面的考虑。首先，如果不强调这一点，某些提供人力外包服务，但又认为自己也蛮懂业务的部门，如研发中心、测试中心、客服中心等也都可以堂而皇之的称自己为中台，这样中台的概念岂不是太泛？其次，一个软件服务的形式的能力和一个以包人头形式提供的能力，所需要的支撑技术未免相差太大，前者可能是微服务，后者可能是个工单系统，这样中台的建设方法岂不是也太泛？所以我认为我们规定中台必须提供软件服务为好。钟华老师也在书中强调中台“仅以服务方式对外提供访问”。

这个定义可以拿最典型（业界落地最多）的数据中台来测试一下，因为数据中台的样子大家比较清楚，可以发现数据中台完全符合上述的中台定义：

• 数据中台是个组织：数据中台都有专职的建设团队，有很多数据工程师，做很多数据加工工作。即便是通过甲乙方项目制来做，也是需要实施团队比较重的投入的。

• 数据中台提供的能力有业务属性：数据工程师是需要比较懂业务的，数据中台提供的指标、模型和数据服务都是业务术语。

• 数据中台的能力是以软件服务的形式提供的：这就是阿里提出的OneService，今天这已经成为所有数据中台服务商的共识。

我们的中台，阿里最初的双中台，还有业务比较认可的字节App工厂中台，也都很好的符合我给出的这个中台定义。

我的定义和业界我认为真正懂中台的专家的定义也是类似的。钟华老师作为业界第一个出书的专家，在新书中给中台下的定义是“将企业的核心能力以服务化形式沉淀到平台…”；王健老师定义中台是“企业级能力复用平台”。我的定义和钟华老师和王健老师没有根本差异，主要是侧重点的不同。

当然了，中台仍是新生事物，仍没有严谨的方法论，正如我现在给的定义和两年前略有不同一样，我们所有人对中台的认知也都在逐步提升的过程中。钟华老师的新书和原书相比对中台的理解就有了很大的发展，王健老师的专栏相比19年的系列文章也有很大提升。

我曾经跟付晓岩老师开玩笑说现在业界就等您来给中台搞个严谨的方法论了，因为付老师之前没去IBM的时候曾说中台没有严谨的方法论，就缺IBM来整个方法论，而今年付老师跑到IBM去了。不过付老师天天写“中台之上”的企业架构，似乎对中台并不太感兴趣。

06

国际顶级研究机构怎么看中台

中台在国内搞的声势浩大（当然也有说中台烂大街的），那么Gartner等国际顶级机构怎么看中台呢。

Gartner

Gartner每年发布一次《Hype Cycle for ICT in China》报告，中台（Middle Platform）在去年的报告中首次出现，但今年又消失了，数据中台（Data Middle Office）也是去年首次出现，在今年不但得以保留，且在Hype Cycle曲线上明显前移。印象中Gartner还出过一篇很长的介绍数据中台的文章，可视作Gartner对数据中台的官方解释（可惜的是没找到这篇文章）。很有意思的是Gartner对数据中台和中台用的是两个词，一个是Office一个是Platform，我为此甚是困惑，还专程向Gartner请教过。

Forrester

Forrester的态度比较微妙，出过一个专门的讲数据中台的报告，但除此之外对中台似乎只字未提。该报告是2019年6月出的，看似是比Gartner更早认可数据中台，但细看可以发现这个报告其实是产商（数澜）赞助报告，而在此之后Forrester似乎又再也没提过数据中台。这点蛮奇怪，所以我稍微深挖了一下，发现原来Forrester后来认为数据中台就是自己说的“企业洞察平台”，就不再单独说数据中台概念了。

IDC

IDC去年底曾经出过一个《CIO视角：企业数据智能实施部署指南》报告提及数据中台，但这个报告的主题还是数据智能，对数据中台是什么似乎也没有很明确的解释，感觉IDC似乎把数据中台当作数字化平台也就是数据智能整体解决方案的别称。IDC也曾经在一份报告中提及AI中台的概念，但后续没有持续关注。IDC对中台没有给过任何评价，对数据中台和AI中台的提及也是局部和短期的，IDC似乎也更中意自己的数据智能概念，不清楚怎么摆数据中台这个概念。

总的来说，Gartner、Forrester、IDC这三个最主要的国际IT研究机构对中台概念还在观望，但其中最具权威性的Gartner鲜明的支持数据中台，其他两家虽然名义上没有，但在自己的术语体系内也是认可数据中台的。因此可以说，数据中台概念已经获得国际顶级研究机构的一致认可。

作为分析机构，都尽可能的希望把业界实践纳入自己的话语体系，似乎这样才显得自己的领导地位。我觉得完全没必要，像Gartner那样大大方方认可数据中台才是高明的。

07

业务中台的简明方法

为业务中台提出一套标准的建设方法和支撑技术很难。之前已经介绍过，业务中台的概念目前还未获得Gartner等顶级研究机构的认可，说明这些分析机构对业务中台还没有达成共识。业界的案例分享也主要介绍中台的建设背景和内容，但对怎么建讲的很少。

以下是我小结的业务中台简明方法，包括方法论和技术两方面。这个简明方法主要是参考了我们自身经验、钟华老师的书和钟华老师创业担任CEO的比升科技的介绍、ThoughtWorks王健老师的文章和极客时间专栏《说透中台》及滴滴等案例。目前业界系统性的介绍业务中台建设方法的还是首推钟华老师和王健老师，其中钟华老师的书（第一本）更侧重技术，王健老师的专栏更侧重方法论。

方法论层面，目前看来最具体系的应该是王健老师在专栏中提出的D4模型，即把中台的建设分为Discovery、Define、Design和Delivery四个阶段，对每个阶段，王健老师还进一步给出了一些具体方法，如：

• Discovery阶段：采用Portfolio Discovery（PD）方法（一种头脑风暴工作坊），自上而下和自下而上结合，建立对企业和行业的“全面视野”。

• Define阶段：采用领域驱动设计（DDD）和事件风暴方法对业务流程背后的问题域进行分析。

• Design阶段：确定中台产品的愿景和业务范围，然后借助设计思维、用户旅程图、服务蓝图等方法进行设计和梳理，并从MVP起步进行迭代。

• Delivery阶段：采用精益产品研发流程，做好中台的运营、治理和演进。对用户分级，头部用户提供专家级服务，快速响应，尾部用户提供自助式服务，降低服务成本。

王健老师的D4模型很全面，但不是说所有中台的建设都必须完整的应用这些方法，特别是非企业级的“小中台”，可以进一步简化。从我们的经验和业界的一般观点看，业务中台最核心的方法论是D4中的以下两点：

1. 采用DDD或事件风暴方法梳理中台板块的边界；

2. 采用精益产品研发流程，从MVP开始，做好中台的运营、治理和演进。

技术层面主要是SOA和微服务、DevOps、流程与规则、API网关。

SOA和微服务一并来说。中台的能力以软件服务的形式提供，因此必须有某种SOA技术支持，微服务则是最典型的SOA实现。不过中台未必微服务，这是我、钟华老师和王健老师的共同观点。中台解决的是业务领域的业务复用问题，微服务解决的是技术领域的“组件编译时依赖”问题（王健语），因此中台未必基于微服务，其他SOA技术也可以。采用哪种SOA主要取决于需求和基础，互联网企业自然会选择微服务，但非互联网行业存在大量的传统SOA架构，基于已有的SOA架构资产建设中台也并非不可行，性价比有时也更高。不过有条件的情况下我还是会建议优先采用微服务架构，包括服务网格，因为毕竟这才顺应技术的演进方向。

中台采用精益产品研发流程，需要快速响应多个前台的需求，因此DevOps技术对中台至关重要。如果没有成熟的DevOps技术支持，中台要么响应慢，要么乱糟糟的仓促上线经常出事，这两种情况都可能导致前台对中台怨声载道，导致中台建设的失败。

前台使用中台能力典型有两种方式：组合和配置。组合通过微服务等SOA方式实现，配置则主要通过流程和规则引擎支持。我们在建设严选中台时发现，仅靠微服务机制并不能很好的实现中台，流程和规则引擎也很重要；滴滴的分享中也提到中台实现的一个核心点是配置化，很多业务都是配置出来的；钟华老师的比升科技也重点提到业务可配置、能力可扩展。因此，流程与规则引擎也是中台的常见支撑技术。

最后是API网关。中台的能力都以服务的形式提供，大量的服务需要的治理能力，可以借助API网关。当然，像阿里这样的超大规模的中台需要更专业的中台能力治理平台，但不复杂的中台，采用API网关是比较方便的做法。

我在两年前的文章[[怎么建设中台]]里还提到云原生技术和分布式事务技术，今天没提分布式事务是因为它应该是微服务技术栈的一部分，没提云原生技术是因为它和中台的距离又远了一层。和两年前相比我增加了流程与规则和API网关。我没有提统一的登陆和权限等内容，这些更基础的能力当然也是需要的，只是和中台的特色不是太相关。

小结一下，业务中台的简明方法包括方法论层面的DDD和事件风暴、精益产品研发和技术层面的SOA和微服务、DevOps、流程与规则、API网关。

08

中台与组织

组织是中台的核心，因此业界有很多关于中台组织的观点，如最常听到的说法是中台必须是企业级的，必须是一把手工程，另一方面业界对中台组织本身的特点和管理方式又很少谈。我在两年前的文章里提到中台未必是企业级的，也可以是事业部级的。中台的组织形态有多种，有“胖中台组织”、“标准中台组织”，也可能退化成平台。这两年来很高兴不少业界同仁也持有类似观点。

1. 中台未必企业级和一把手工程

大量的实践表明，大多数中台并非企业级，我们的中台绝大部分都是事业部甚至是子业务级，滴滴的中台也是从出行业务一步一步发展而来，京东有不少子业务内部的中台（如购物车中台），至于农行那样的中台规划则实际上很可能没落地。即便阿里的中台也主要局限于电商业务，支持不了云业务，而且后来阿里也拆了大一统的中台，变为“互为中台”。

中台必须是一把手工程多数情况没错，但不能狭隘的理解，更不是必要条件。

不能狭隘理解一把手必须是CEO，甚至不能理解为必须是事业部总经理，而应该理解为中台涉及范围的一把手。我们严选的数据中台做的很不错，但其实在很长时间里，严选的CEO并不关注，但严选数据中台确实得到严选CTO的大力支持，严选的CTO就是这个环境下的“一把手”。乙方往往喜欢宣扬中台必须是一把手工程，我感觉其实也带着筛选客户的考虑，因为一把手重视单子才能做大也容易交付，一把手不重视则单子小、风险高。但对于甲方自己想建中台，从更低层级的中台起步往往是更好的做法。

中台也未必是一把手工程，优势部门做中台再推广也是一条路。我们的数据中台是集团级的，但并不需要老板下指令，而是基于杭研业务数据基础，再和其他业务互惠共赢不断做大的。滴滴的中台也是出行业务做了后再推广到其他业务的，企业业务是否接入中台并不强制。这样的做法也有优势，这样的中台肯定是创造价值的，肯定是有利于创新而非阻碍创新的。

所以，我认为非企业级的中台并非中台还未建成的表现，而是中台的未来发展方向。中台的发展方向是分布式中台，也就是组织内部存在不同层次的多个中台。老K在《中台彻底搞砸了？下一站，小中台大前台》中提出中台的演进方向是小中台和碎片化中台，如安全中台、财务中台、物流中台等等，我说的分布式中台和老K说的碎片化中台是一样的概念，只是感觉碎片化比较负面，称分布式更好。

分布式中台是趋势除了以上原因，还因为中台作为一种组织形态和权力分配息息相关，而企业组织的大趋势一定是分权而非集权。阿朱介绍的阿里中台的诞生历史就充满权斗的意味，老逍是通过大搞中台削诸侯的权。我们不要把阿朱的话当作细说，我观察我们中台的建设，很多或多或少也存在权力的争抢，中台部门当然希望争取更大的业务范围，而前台部门也经常以中台支持不力为由把权限抢回去。北京大学光华管理学院教授、光华创新中心主任张一驰教授更是认为“企业中台化浪潮实际上是以横向水平分割的方式来解决集权和分权平衡的问题的，其目最终目的是实现责任和权利在各个组织层级之间的长期动态平衡”。从组织管理的角度，张教授可能说出了中台的本质。

2. 中台的组织形态

我在两年前的文章曾提出，“标准中台组织”只应该包含共享的能力，但为了解决和前台业务结合不够深，合作不够顺畅，可以把相关前台的部分团队也整合到中台，从而形成“胖中台组织”。阶段性的可以让中台组织长的过胖一些，让中台和前台的边界在一个组织内磨合，过两年在看哪些是属于中台的骨骼，哪些是属于前台的肉，搞清楚了再把肉重新分到前台去。

这两年我看到业界也提出一些相近的组织方法，一是王健老师在极客时间的《讲透中台》专栏中提到中台的运营和治理可以给用户分级，对最重要的用户可以提供专家级服务，对一般用户则提供自助式服务，此真乃老到之言。字节跳动在分享中提到“数据中台”有“BP团队”，对“前端”业务进行专门的支撑，这类似王健老师说的针对重要用户提供的专家级服务。

我说的“胖中台组织”、王健老师说的“专家级服务”还是字节的“BP团队”，都是在中台组织内除了共性团队，还部署专职面向某些前台业务的定向服务团队。这些团队从我们和一些业界的经验看，应该采取“专人就位”的模式，“专人”指的是支撑一个前台业务的团队是专职的，即便只有一个人；“就位”指的是这些专职人员一定要坐到业务团队中间去。

中台需要给予业务一定的考核权限。我们的经验是最简单且有效的做法是给业务“满意度”考核权，占组织绩效的10%以上即可大概率确保中台组织有志于提供高质量的服务。当然，如果你搞中台的目的是控制权力而非提供服务，那就不要搞这样的考核了。

09

结束语

中台涉及的方面很杂，我无法给出一个要点小结，这个结束语主要是一些整体感受。

首先，通用的中台（即业务中台）在这两年的发展并没有继续爆发。没有获得Gartner等顶级研究机构的认可（曾经在报告中出现过，但都是昙花一现）。方法论上只有王健老师在专栏中提出的D4模型。钟华老师作为第一个面向业界系统性阐释业务中台概念的专家，在其新书和创办的毕升技术公司的介绍中已经不再把中台放在核心位置。业界已经在说中台不行了，但另一方面如果去招标网看看业务中台的招标仍有不少。对此，我认同王健老师的观点，“个体中台可能会死，但中台背后的趋势不会变”。

另一方面，数据中台发展的如火如荼。Gartner已经连续两年为数据中台正名，仅杭州就发展出所谓“杭州五虎”五家代表性数据中台厂商，招标网上今年数据中台方面的标是业务中台的四倍，方法论层面有好几本书（虽然我觉得这些书的内容有点飘），技术方面也在不断进步，如实时数仓、湖仓一体。

中台涉及的组织因素是相当复杂的，即便是数据中台。我们看到阿里中台的起起落落，似乎都和权力分配有关，张一驰教授更是鲜明的提出中台乃是“以横向水平分割的方式来解决集权和分权平衡”。这有时是中台建立的动力，有时给中台建设带来阻力，总之为中台建设带来不确定性。从组织层面，这两年我看业界有更多人认识到两点，一是中台的趋势是分布式中台，二是中台组织内部要有定向服务的团队。

「数据中台篇」

数据中台是目前企业规划建设最多的中台类型，对应的方法论和支撑技术也都最为成熟，但在认知上仍然存在一些模糊之处，方法论和实践上也还在快速发展，这一篇谈谈数据中台的关键问题和发展。

01

数据中台的定义和边界

数据中台是一种特定类型的中台，对照中台的概念，数据中台可以定义为“提供公共数据服务的组织”，职责主要是为整个组织提供标准化、高质量、高效率、低成本、高安全的公共数据服务。

数据中台以数据服务层为边界，这一点是阿里、我们及袋鼠云、数澜、云徙等数据中台厂商的共识。通常来说，在规划建设数据中台时也会同步建设一些上层应用（如报表、数据产品等），因为仅建设中台发挥不了效益，但这些应用本身并不属于数据中台，而是数据中台的支撑对象。如下图我们和数澜给出的数据中台架构图都非常清楚的说明数据中台以数据服务层为界，袋鼠云团队出品的《数据中台架构——企业数据化最佳实践》一书也提到“数据中台应该为可能进行的数据应用提供数据及数据模型支持”。

我们（网易数帆）的数据中台架构

数澜的数据中台架构

但当前也还有一些企业甚至是厂商没有将中台和应用清晰的加以区分，而是笼统的都作为数据中台的内容，如下图国云数据出版的《数字化转型方法论——落地路径与数据中台》一书给出的数据中台架构把大量的数据应用都作为中台的内容。我认为这样的观点是很值得商榷的，因为下图中的很多应用（如智慧门店、智能投保、教学诊改、图书推荐等等）显然并非一种共性能力而是具体的前台业务内容。

国云数据的数据中台架构

强调数据中台不包含应用，主要的原因并不是为了理清数据中台的概念，而是因为这对建设好数据中台非常重要：

• 数据中台和应用在建设和管理上应当是解耦的。数据中台的内聚度很高，应该由一个团队来建设，如果由乙方来建也只能交给一个乙方（当然如果一个组织建设多个数据中台的话不同的数据中台交给不同的团队或供应商也没问题），但应用完全可以由各个前台团队分别建设，不同的应用交给不同的乙方也没问题。

• 数据中台和应用所需的支撑能力非常不同。数据中台一般需要的是数据集成、数据开发、数据治理、数据仓库等技术支持，但数据应用则一般需要数据报表、敏捷BI、数据可视化乃至通用的应用开发机制支持。

因此，如果数据中台和应用不分，那么只能都交给一个团队或一个乙方来建设，这就人为的大幅提高了对团队或乙方的要求，导致建设难度无谓增加。

虽然我们一直致力于同时提供数据中台和数据产品的建设能力，但我们也一直秉承解耦的理念，从不宣扬数据中台和应用是密不可分的，这是因为关注架构的“高内聚、低耦合”已经深入我和团队的骨髓。

一个常见问题是数据中台要不要包含面向各个业务的应用数据层。这个问题各路专家的观点比较不一致，如：

• 阿里《大数据之路：阿里巴巴大数据实践》一书介绍阿里的数据中台只是建设集团的数据公共层。

• 我们集团级数据中台仅负责数据公共层，但严选、音乐等业务级的数据中台团队也会负责某些业务（但不是所有）的数据集市层。

• 车品觉老师在《决战大数据》中强调“数据公共层最重要，基础层必须统一”、“决策分析最好放中台部门，业务分析可放业务部门”，这样看来品觉老师应该建议数据中台仅负责数据公共层。

• 钟华老师没有直接解答这一问题，但书中提出“数据中台包含垂直数据中心、全域数据中心和萃取数据中心”，适合纳入中台的第一条标准是“功能和数据具备共享价值”，由此看来钟华老师也是建议仅包含数据公共层的。

• 数澜在《数据中台——让数据用起来》一书中给出的数据中台建设范围包含了应用数据层。

汇总以上观点，我认为数据中台是否应该包含应用数据层取决于团队能力和需求灵活性。如果前台部门的数据能力较弱，对数据的需求变化较少，则数据中台包含应用数据层可能能提供更好的支撑，反之如果前台部门数据能力较强，需求变化多样，则对应的数据应用层最好由前台部门自行建设。要是从组织层面，也可以理解为看中台和前台哪个部门势力大。

02

数据中台怎么建

数据中台是对已有一系列数据分析、治理相关技术和最佳实践的综合和发展，不是一个全新的概念和全新的技术。因为有良好的理论基础，加之行业头部企业和服务商的共同努力，现在已经有了比较成熟一致的方法和工具支持。在数据中台行业，有一个“杭州五虎”的戏称，指的是都在杭州的五家服务商，我们、阿里、袋鼠云、数澜和云徙，其中前四家都是获Gartner认可的数据中台代表性厂商（Sample Vendor）。数据中台这个行业将来影响力壮大了，杭州可以说是“数据中台之都”啊。

我们在极客时间《数据中台》专栏中详细介绍了数据中台的建设方法，可能是业界介绍数据中台里最接地气的。袋鼠云、数澜等友商也都出了相关的书，当然也都可以参考，这些书会偏宏观一点。本文简要介绍数据中台建设方法中的核心内容。

数据中台建设方法的核心内容包括方法论和技术两个维度。方法论维度主要是分析框架及指标体系、数据仓库、数据治理和数据网关，技术维度主要是数据开发和数据湖。在此，我并未提及诸如坚定战略、顶层设计、组织变革等高阶方法论，这是因为我们认为数据中台的建设在组织的很多层次都可以进行，而且最好采取迭代演进的方式，因此大多数情况下并不需要那些高阶方法。在此，我也未提及诸如理现状、立架构等常规“咨询套路”，这些当然都是需要的，但面向数据中台的建设的针对性不强。

数据中台建设方法论

A. 分析框架和指标体系

指标体系是数据中台的牛鼻子，是数据中台提供的服务的主体。虽然数据仓库维度建模中的度量和指标很像，但我认为指标体系应该是一套独立的方法论，通过业务流程分析并经由原子指标、派生指标、修饰词等形成规范的指标建设和管理方法，是数据中台方法论超出传统数据仓库的创新之举。可惜的是最近两年的几本新书对指标的体系化建设大多语焉不详，详细介绍看起来主要还是在我们的极客时间专栏或阿里最初的那本书。

这两年我们在不断深入行业的过程中，越来越体会到分析框架的重要性。车品觉老师在《决战大数据》一书中曾多次强调分析框架的重要性，认为分析框架是“数据产品的养分”，是“数据收集的瞄准镜”。分析框架反应了核心的业务逻辑，如营销侧的AIPL、RFM等框架，零售的“总销量=流量 x 转化 x 客单价 x 复购”大逻辑，连锁零售要紧密围绕“门店数量、单店收入、品效、坪效”等做文章。如果不能深入的理解和灵活运用这些核心的分析框架，就不容易把数据中台规划建设好。因此，我认为在业务流程分析法之外，分析框架的指导也应该作为指标体系建设的重要方法。

B. 数据仓库

数据仓库为数据中台建设提供了最主要的方法论基础。数据仓库领域有两套截然不同的基本方法，一个是数据仓库之父Bill Inmon所倡导的至上而下的方法，另一个是Kimball所倡导的至下而上的方法。从这两年的业界实践来看，维度建模方法基本上讲已经大获全胜，因为这个方法可以一个业务过程一个业务过程的实施，不需要顶层设计。这也顺应了之前介绍的分布式中台趋势。

C. 数据治理

数据治理为数据中台提供了核心保障。这里说的数据治理是包括元数据管理、主数据管理、数据标准、数据质量管理、数据资产管理、数据安全等系列方法的统称。这些方法中，元数据是数据中台提供服务的一部分，主数据管理和数据标准和数据中台OneID的概念比较接近，同时也为数据仓库的维度建模提供了规范的维度数据，数据质量管理、数据资产管理、数据安全等则分别用于提升数据中台的质量、成本经济性和安全性。

D. 数据网关

数据网关在落地时一般称为数据服务，但从思想和方法论层面，是一种网关。网关作为一种企业架构模式的流行，使得数据中台拥有一个清晰的服务形式和界面，这一点在经典数据仓库实践中是没有的，也属于数据中台相对数据仓库的创新。在网关层面，可以实现协议转换、语法标准化、逻辑模型与物理模型解耦及众多安全性和服务治理职能。

阿里的数据中台建设方法论是OneData，包括OneID、OneModel和OneService，我介绍的方法论和阿里核心是一致的，是对阿里方法论的细化和扩展。数据治理包含了OneID，指标体系和数仓对应OneModel、数据网关对应OneService。

数据中台支撑技术

A. 数据开发

数据开发是数据中台实施的最后一公里。指标的计算、模型的产出，最终都要经由数据开发动作来实现。数据开发又大致包括数据集成、逻辑开发和任务运维等几个方面。数据集成除传统的数据库CDC等技术外，还可能涉及互联网应用的数据埋点、文件传输、API集成等方式；逻辑开发需要专业的IDE、CI /CD、版本控制等系统支持；任务运维也需要全链路数据血缘、运维基线、一键修复等专业能力的支持。

B. 数据湖

数据湖为数据中台提供了便利的技术底座。数据中台之所以能够比较方便的低成本实施，和以HDFS和对象存储为代表的数据湖技术的成熟是很有关系的。在数据湖之前，传统的数据仓库技术非常昂贵，可伸缩性也不是很好，这就很难满足数据中台要集中多个系统、多个业务的大量数据的要求。有了数据湖，就可以把数据都集中到数据湖，在此基础上建数据中台就有了一个可控、低成本、可伸缩的技术底座，方便很多。不过在有些情况下因为成本、安全或政治原因，没有办法基于集中式的物理数据湖建数据中台，业界正在开发“逻辑数据湖”等技术解决这一问题。后面我会再具体介绍逻辑数据湖。

其实数据中台所需要的支撑技术远不止数据开发和数据湖两个，方法论的四个维度都需要各自的支撑技术。指标体系需要指标管理系统，数据仓库需要模型设计和管理系统，数据治理需要的支持系统就更多了（如元数据中心、质量中心、资产中心、安全中心等），数据网关作为对外服务接口对性能和管理的要求则非常高。因为这一节重点是介绍方法而非技术，所以没有展开说明。

小结一下，数据中台的建设方法主要是在分析框架指导下通过业务流程分析梳理指标体系，采用Kimball为主的数据仓库建设方法完成数据模型的设计和开发，并以数据服务的方式提供，同时通过数据治理保证数据中台的质量、成本经济性和安全性。

03

数据中台前沿趋势

上一节介绍数据中台建设的基础方法，此外，以下前沿进展和趋势也值得关注。涉及前沿很难给出比较全面的综述，我说的这些主题都是那些业界讨论比较多也有一定实践的小热门主题。

1. （准）实时数仓和批流一体

我之前曾经提了个口号叫“人人用数据，天天用数据”，现在看这个口号似乎得稍微改一下，应该是“人人用数据，时时用数据”，因为基础比较好的企业已经在实践实时数据中台了。我说的实时数据中台指的是所有实时性超越T+1的数据中台，大概率是10分钟到小时级的需求，并非那种秒级的高实时需求，因此其实是准实时。举几个例子，音乐算法的A /B测试需要半小时出结果，有些先进的连锁零售点已经可以做到每天配送2次或更多，物流调度每天也需要多批次，这就需要小时级的决策支持。

实时数据中台的建设方法论和普通（离线）数仓是一样的，但所需要的技术支撑却大不相同。这是因为典型的Hadoop系数据湖技术支持不了这样的实时性需求，计算引擎也需要由典型的MapReduce / Spark换成Flink。我说的是Hadoop体系的技术栈，传统技术栈我还不好判断。

虽然实时数仓已经有不少的案例分享，但因为缺乏成熟的技术支持，目前大多数采用Lambda架构，和离线数仓是完全独立的两条链路，由此导致大量的冗余，整个架构高度复杂，成本高，且实时部分的能力受限。也有采用Kappa架构，也就是完全用Kafka+Flink这样的实时技术来实现的，但在我看来这些案例并非能力全面的数仓，在转换汇总计算复杂度和数据保留周期等方面都存在严重不足。

业界多个机构和社区都在努力研发一套基于Hadoop体系真正全面支持实时数据仓的技术，核心是“湖仓一体”和“批流一体”。

“湖仓一体”就是在HDFS体系内支持实时数仓，主要的苗子是Delta Lake、Hudi、Iceberg三剑客，但我们觉得都不太理想，Delta Lake因为Databricks背景和Spark绑定过深，Hudi虽然阿里初步解决了Flink兼容性，但和Spark耦合的痕迹仍在，且架构比较复杂（如对HBase有依赖），Iceberg的架构最干净但功能也最不完整，且社区的发展方向有很大隐忧。我们、阿里和腾讯都在努力完善Iceberg，但我们也在大力研发另一个湖仓一体技术Arctic。Arctic的优势是对底层依赖最少，基本有HDFS的地方就能跑，且和任何一个计算框架都没有强耦合，目前已经在云音乐和一些外部客户应用。

实时数仓从技术上还依赖“批流一体”。湖仓一体技术可以做到批和流的存储一体，但还需要进一步解决元数据一体、代码一体等问题，让离线和实时数仓链路全方位合二为一，消除资源和工作量冗余，这样实时数仓才能大范围普及。这块包括我们在内，整个业界都还在努力。

2. 逻辑数据湖

在完美世界中，应该有一个集中的数据湖系统（如HDFS或对象存储）存储了所有数据并支持中台、数仓、算法等各种场景，但由于成本和安全等原因，这样的做法不可行或不理想，也可能因为目标是建设数据中台，数据湖并非重点，最好不要引入一套新的技术栈。如此种种原因，都导致需要发展逻辑数据湖技术，在逻辑层面将数据加以整合，但物理层面分散在原有系统之中。

逻辑数据湖的技术还在发展中，Gartner在今年刚发布的Hype Cycle for ICT in China报告中指出当前的数据中台实践采取的是把所有数据集中到一处的“collecting”模式，缺乏连接多个系统的“connecting”模式，现状确实如此。虽然一些产商宣称支持逻辑数据湖，但并非通过成熟的产品提供，而是根据客户的当前需求进行定制开发，这就导致逻辑数据湖的实施成本高，且不能满足后续的需求变化。要提供成熟的逻辑数据湖技术，需要做到数据源的自动接入、元数据的全链路打通、在一个平台进行数据开发、数据治理在一个平台统一进行、权限的统一管理等很多特性，让逻辑数据湖和物理数据湖在研发侧、运维侧、治理侧的表现高度一致。云巨头可能因为战略原因在这条路上不积极，他们的策略通常是说服客户从传统的TD、GP、Vertica等MPP迁移到Hadoop体系或自家的ADB、GaussDB等产品，包括我们在内的数据中台产商应该都认可这一路线，大家的区别在于产品力。

业界有几个和逻辑数据湖相关的概念：Data Mesh、Data Fabric、Data Virtualization。这些技术的提出者包括大名鼎鼎的Gartner和ThoughtWorks。这些概念都打着反对数据湖的旗号，但在我看来他们反对的只是物理上大集中的数据湖，他们推动的方向在数据中台的场景下自然会走到逻辑数据湖。这也进一步说明了逻辑数据湖已经成为一个很有影响力的新趋势。

可能在未来物理数据湖最终会是绝对主流，但在当前的技术环境下，逻辑数据湖兼容并包的体质才能满足更多场景。业界应该加强对逻辑数据湖的认知，不要认为数据中台就必须新建一套数据湖，完全可以在已有的Teradata、Oracle、GreenPlum、Vertica等基础上建。数据湖和数据中台的建设，除了collecting模式还有connecting模式。

3. CI/CD和DevOps

Gartner的Hype Cycle for ICT in China报告也提到缺乏XOps（DataOps、ModelOps、DevOps）技术支持是当前数据中台建设面临的问题之一。Gartner的提醒是对的，因为数据中台离前台业务仅一步之遥，对敏捷的要求较高，需要不停的迭代更新，另一方面数据中台是整个系统的中枢，又要保障稳定，解决这两者之间的矛盾，如果没有成熟的CI /CD等DevOps技术支持，建设的难度和风险都会增加。这里我统一使用DevOps术语，虽然可能DataOps的说法更时髦也更贴近数据中台的环境，但从抽象层面我觉得DataOps和ModelOps都是DevOps的特例。

DevOps能力并非是完全缺失的，我们和阿里都提供了一些支持，比如开发 / 生产环境的隔离和统一管理，数据测试等，但总的来讲，目前数据开发领域的DevOps能力和通用软件开发领域的成熟度还不能比。作为一个老程序员，我在两年前就觉得这是个问题，因此安排团队进行开发。要做到成熟的DevOps，需要很多环节的工具支持，如版本控制、灰度发布、测试自动化、环境隔离等等，这样才能在快速迭代中有信心高频发布上线。但数据开发和普通软件开发毕竟也有本质不同，核心是处理的数据量大，由此导致难以精确测试验证、测试时间长、错误导致的数据成本高等问题，所以得用不一样的手段，如测试通常就通过数据形态探查这样比较模糊的方式而不是普通软件测试通过精确的assert进行、测试数据集往往通过采用而不是构造（构造会造死你）的方式进行。

这个领域的技术和数据质量方面的技术是相通的，我在之前的文章（[[数据基础设施创新如火如荼，主要方向有哪些（上）]]里提到目前国际上也有多家厂商在这个领域发力，如Bigeye、Monte Carlo、Great Expectations等，但似乎国内厂商都没有集成这些技术，当然前两个都不是开源组件，难以集成。

一个普通软件开发进到数据开发领域，大概会觉得这个世界怎么干啥都慢，就像《疯狂动物城》里的Sloth（树懒）一样。（话说我们有个同事就把我们的流计算平台取名叫Sloth，这程序员幽默我也很无奈）

04

小结

小结一下，数据中台是“提供公共数据服务的组织”，目的是为前台业务分析提供标准、一致、高质量、高效率、低成本、安全的数据服务。数据中台的范围以数据服务层为边界，不要包含更上层的数据应用或数据产品。数据中台建设方法的核心内容包括方法论和技术两个维度。方法论维度主要是分析框架及指标体系、数据仓库、数据治理和数据网关，技术维度主要是数据开发和数据湖。（准）实时数仓和批流一体、逻辑数据湖、CI/CD和DevOps是几个值得关注的数据中台发展新趋势。